Interoperability Case Studies

Public health systems have been developed over many years and are costly to maintain or replace. Service-oriented architectures (SOA) have provided a way for these systems to remain viable and responsive to increasing demands for information and analysis. As healthcare entities look for strategies to effectively achieve “meaningful use:” of their EHR systems, SOA will emerge as one key technical strategy for enabling this functionality. This paper offers two case studies of core public health systems in different jurisdictions and the strategies used with SOA to extend system life and to enable new and important features. FEATURE: PUBLIC HEALTH www.himss.org VOLUME 24 / NUMBER 2 SPRING 2010 JHIM 45 PUBLIC HEALTH SYSTEM EVOLUTION Over the past several years, public health systems have evolved significantly, both from a technical and programmatic standpoint. Many of these systems began in the 1980’s (or even earlier) as program-specific, stove-pipe systems often based on aging mainframe or early, weak standalone personal computer technologies (Figure 1). These systems originated in a variety of places. The Centers for Disease Control and Prevention (CDC) provided many such applications to health agencies thirsting for automation solutions. Users of these systems were often epidemiologists and others with public health analytical skills which they used to perform “programming” functions to tweak system functionality and performance to match the requirements of their jobs and to supplement the agencies’ limited information technology staff. These agencies often had little or no internal capability or expertise to develop core information systems, as the information services function of these agencies was quite new and more focused on basic computing needs: desktop support, personal productivity applications like text processing and electronic spreadsheets, and basic network connectivity to support file and printer sharing. In these early years the Internet was just emerging as a mainstream, general purpose information highway; email was still a distant dream. Unfortunately, the CDC itself had limited funds and limited expertise in software development. What began as innovative applications over time became limited systems that did not keep up with changes in hardware and operating system capabilities, nor at times keep up with changing functional requirements (Table 1). As personal computers became more powerful and operating systems became more useable with the advent of Microsoft Windows, two things began to occur. First, for a lucky subset of systems, CDC was able to update the products to make use of these more modern features and capabilities. Software was updated from DOS to MS-Windows. Additional printer support was added. In some cases, networking features were added to allow simple multi-user access. Second, public health agencies themselves began to recognize that information technology was a legitimate target for investment to improve their ability to perform core public health functions. Agencies began, on their own, to upgrade, replace, or create new systems that were more robust and specialized using modern database management systems and tools on more reliable platforms. The Internet began to come into its own, and the CDC promoted its first wide area communication and system integration projects through its Information Network for Public Health Officials (INPHO) initiative in 1993. As the years went on, some agencies recognized the limitations of deploying systems purely within individual programs when the information related and their limited funds for technology could be better spent if leveraged across multiple projects. As applications became more network-aware and network-dependent, the need to leverage network investments became critical. Similarly, as systems moved to use more sophisticated relational database management systems (RDBMS) the pressure to share these expensive software licenses increased. These agencies developed a broader vision and some of their systems evolved into integrated systems supporting a wider variety of patient-centered or case-centered functions. But funds have still been limited, and investments in information technology compete with other priorities within an agency. Extending the life of existing systems, while reducing their maintenance cost, is an important priority for any budget-conscience program. PUBLIC HEALTH REGISTRIES A public health registry is defined as, “...an organized system for the collection, storage, retrieval, analysis, and dissemination of information on individual persons who have either a particular disease, a condition (e.g., a risk factor) that predisposes to the occurrence of a health-related event, or prior exposure to substances (or circumstances) known or suspected to cause adverse health effects.”4 Immunization Registries, or Immunization Information Systems (IIS), are “confidential, computerized information systems contain vaccination histories and provide immediate access to a child’s current Fig. 1: System Evolution. Table 1: CDC Applications. 46 JHIM SPRING 2010 VOLUME 24 / NUMBER 2 www.himss.org immunization status to authorized providers. As a centralized, secure site of single record storage they provide an official immunization record for school, day care, and camp entry requirements.”5 Some of these systems have been in operation for ten or more years and continue to expand and evolve. Early IIS were often deployed as client/ server systems with traditional architectures.6 As the Internet became more prevalent and stable, these client/server systems migrated to the World Wide Web either delivered through terminal services (e.g., Citrix) or rewritten as native Web applications. No single application technology currently dominates (e.g., .NET versus Java). These applications have provided two major functions: (1) provided an interface for data collection, as a primary purpose of the IIS is to consolidate immunization records from multiple sources; and (2) to provide decision support for the clinician to help ensure that patients (initially children, but increasingly adults as well) are immunized on time and, also, are not over-immunized. While online applications began as a major tool for data collection, there has always been a strong movement within the IIS community to collect data electronically. The primary motivation for this strategy has been the existence of local provider-based information systems – both clinical systems and more administrative practice management systems – that are used by providers. Data is entered into these local systems and providers have been loath to re-enter data into an IIS application. Most IIS offer some capability for absorption of records extracted from these local systems, though these extracts are most often created in proprietary formats that vary from jurisdiction to jurisdiction. Efforts to standardize these formats have primarily focused on Health Level 7 (HL7) and more recently on IHE. Interestingly, a small number of IIS have promoted the reverse model: providers are instructed to enter data into the IIS first and then exports are enabled from the IIS to the EHR-S or other local system. This strategy is aimed at ensuring that providers use the IIS for decision support, since most local systems do not have the complex algorithms necessary for assessing immunization history for a patient and accurately predicting whether the patient is up-todate or in need of one or more immunizations. Certification criteria promoted by the Certification Commission for Health Information Technology (CCHIT) for both ambulatory and in-patient EHR-S do not yet include very many pediatric health functions, and Advisory Committee on Immunization Practices (ACIP) guidelines are some of the most complex to implement in systems.7,8 As more and more healthcare providers are using electronic health record systems (EHR-S) in their offices to maintain clinical records on their patients, IIS projects are developing the capability for interoperability with these EHR-S. This interoperability will become more important and necessary as providers seek to reduce the number of system interfaces and focus their data exchange on health information exchange networks (HIEN) that are emerging in their areas. Proprietary file formats for IIS data collection are being replaced by standards-based formats. But the push for standardization extends beyond that: providers are demanding standard data transport methods, as well as servicesbased capabilities to enable more seamless interoperability with their local systems. SERVICE-ORIENTED ARCHITECTURES A wide set of material is available defining and describing Serviceoriented Architecture (SOA) and the technologies commonly used to implement it.9,10 Essentially, SOA is a building-block approach to application development which emphasizes re-use of software components that are built to perform individual functions and which interact with each other through clearly-defined interfaces.11 For public health registries, SOA offers a powerful strategy to bridge old and new technologies, and it offers a way to enable interoperability with external systems that is increasingly required for the provider community with a minimum of retrofit and rework. SOA also offers a strategy for system enhancement through the acquisition or development of modular components that can change over time as needs change, as regulations change, and as clinical guidelines improve. A typical SOA architecture within a single system is displayed in Figure 2. More extensive extrapolations of these basic concepts have been implemented in enterprise-wide deployments which, at their extreme, conceive of and deliver all system functionality as a set of services evoked as needed by participating systems. SOA offers some distinct advantages for application development and support, including: Increased scalability through increased modularity: systems components can grow independent of each other as they are loosely coupled through services interfaces. Lower cost through software component reuse: no need to reinvent or redeploy a software module that can be reused in multiple systems. SOA is applicable either to entire systems or just to parts of systems, making it a flexible approach with no single “right answer” in the context of a particular application. •